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Abstract 


The Path Computation Element (PCE) architecture introduces the 
concept of policy in the context of path computation. This document 
provides additional details on policy within the PCE architecture and 
also provides context for the support of PCE Policy. This document 
introduces the use of the Policy Core Information Model (PCIM) as a 
framework for supporting path computation policy. This document also 


provides representative scenarios for the support of PCE Policy. 
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1. Introduction 


The Path Computation Element (PCE) Architecture is introduced in 
[RFC4655]. This document describes the impact of policy-based 
decision making when incorporated into the PCE architecture and 
provides additional details on, and context for, applying policy 
within the PCE architecture. 


Policy-based Management (PBM), see [RFC3198], is a network management 
approach that enables a network to automatically perform actions in 
response to network events or conditions based on pre-established 
rules, also denoted as policies, from a network administrator.  PBM 
enables network administrators to operate in a high-level manner 
through rule-based strategy (policies can be defined as a set of 
rules and actions); the latter are translated automatically (i.e., 
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dynamically, without human interference) into individual device 
configuration directives, aimed at controlling a network as a whole. 
Two IETF Working Groups have considered policy networking in the 
past: The Resource Allocation Protocol (RAP) working group and the 
Policy Framework working group. 


A framework for policy-based admission control [RFC2753] was defined 
and a protocol for use between Policy Enforcement Points (PEP) and 
Policy Decision Points (PDP) was specified: Common Open Policy 
Service (COPS) [RFC2748]. This document uses the terms PEP and PDP 
to refer to the functions defined in the COPS context. This document 
makes no assumptions nor does it reguire that the actual COPS 
protocol be used. Any suitable policy exchange protocol (for 
example, Simple Object Access Protocol (SOAP) [W3CSOAP]) may be 
substituted. 


The IETF has also produced a general framework for representing, 
managing, sharing, and reusing policies in a vendor-independent, 
interoperable, and scalable manner. It has also defined an 
extensible information model for representing policies, called the 
Policy Core Information Model (PCIM) [RFC3060], and an extension to 
this model to address the need for OoS management, called the Ouality 
of Service (Q0S) Policy Information Model (QPIM) [RFC3644]. However, 
additional mechanisms are needed in order to specify policies related 
to the path computation logic as well as its control. 


In Section 2, this document presents policy-related background and 
scenarios to provide a context for this work. Section 3 provides 
reguirements that must be addressed by mechanisms and protocols that 
enable policy-based control over path computation reguests and 
decisions. Section 4 introduces PCIM as a core component in a 
framework for providing policy-enabled path computation. Section 5 
introduces a set of components that may be used to support policy- 
enabled path computation. Sections 6, 7, and 8 provide details on 
possible component configurations, communication, and events. 
Section 10 discusses the ability to introduce new constraints with 
minimal impact. It should be noted that this document, in Section 4, 
only introduces PCIM; specific PCIM definitions to support path 
computation will be discussed in a separate document. 


1.1. Terminology 


The reader is assumed to be familiar with the following terms: 


BEEP: Blocks Extensible Exchange Protocol, see [RFC3080]. 
CIM: Common Information Model, see [DMTF]. 

COPS: Common Open Policy Service, see [RFC2748]. 

CSPF: Constraint-based Shortest Path First, see [RFC3630]. 
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LSP: Label Switched Path, see [RFC3031]. 

LSR: Label Switching Router, see [RFC3031]. 

PBM: Policy-Based Management, see [RFC3198]. 

PC: Path Computation. 

PCC: Path Computation Client, see [RFC4655]. 

PCCIM: Path Computation Core Information Model. 

PCE: Path Computation Element, see [RFC4655]. 

PCEP: Path Computation Element Communication Protocol, 
see [PCEP]. 

PCIM: Policy Core Information Model, see [RFC3060]. 

PDP: Policy Decision Point, see [RFC2753]. 

PEP: Policy Enforcement Point, see [RFC2753]. 

OPIM: OoS Policy Information Model, see [RFC3644]. 

SLA: Service Level Agreement. 

SOAP: Simple Object Access Protocol, see [W3CSOAP]. 

TE: Traffic Engineering, see [RFC3209] and [RFC3473]. 

TED: Traffic Engineering Database, see [RFC3209] and [RFC3473]. 


TE LSP: Traffic Engineering MPLS Label Switched Path, see 
[RFC3209] and [RFC3473]. 
WDM: Wavelength Division Multiplexing 


2. Background 


This section provides some general background on the use of policies 
within the PCE architecture. It presents the rationale behind the 
use of policies in the TE path computation process, as well as 
representative policies usage scenarios. This information is 
intended to provide context for the presented PCE policy framework. 
This section does not attempt to present an exhaustive list of 
rationales or scenarios. 


2.1. Motivation 


The PCE architecture as introduced in [RFC4655] includes policy as an 
integral part of the PCE architecture. This section presents some of 
the rationale for this inclusion. 


Network operators reguire a certain level of flexibility to shape the 
TE path computation process, so that the process can be aligned with 
their business and operational needs. Many aspects of the path 
computation may be governed by policies. For example, a PCC may use 
policies configured by the operator to decide which optimization 
criteria, constraints, diversities and their relaxation strategies to 
reguest while computing path(s) for a particular service. Depending 
on SLAs, TE and cost/performance ratio goals, path computation 
reguests may be issued differently for different services. A given 
Service A, for instance, may require two Shared Risk Link Group 
(SRLG)-disjoint paths for building end-to-end recovery scheme, while 
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for a Service B link-disjoint paths may be sufficient. Service A may 
need paths with minimal end-to-end delay, while Service B may be 
looking for shortest (minimal-cost) paths. Different constraint 
relaxation strategies may be applied while computing paths for 
Service A and for Service B, and so forth. So, based on distinct 
service reguirements, distinct or similar policies may be adopted 
when issuing/handling path computation reguests. 


Likewise, a PCE may apply policies to decide which algorithm(s) to 
use while performing path computations reguested from a particular 
PCC or for a particular domain, see [RFC4927]; whether to seek the 
cooperation of other PCEs to satisfy a particular reguest or to 
handle a reguest on its own (possibly responding with non-explicit 
paths), or how the reguest should be modified before being sent to 
other member(s) of a group of cooperating PCEs, etc. 


Additional motivation for supporting policies within the PCE 
architecture can be described as follows. Historically, a path 
computation entity was an intrinsic part of an LSR's control plane 
and always co-located with the LSR's signaling and routing 
subsystems. This approach allowed for unlimited flexibility in 
providing various path computation enhancements, such as: adding new 
types of constraints, diversities and their relaxation strategies, 
adopting new objective functions and optimization criteria, etc. All 
that had to be done to support an enhancement was to upgrade the 
control plane software of a particular LSR (and no other LSRs or any 
other network elements). 


With the introduction of the PCE architecture, the introduction of 
new PCE capabilities becomes more complicated: it isn't enough for a 
PCE to upgrade its own software. In order to take advantage of a 
PCE's new capabilities, new advertising and signaling objects may 
need to be standardized, all PCCs may need to be upgraded with new 
software, and new interoperability problems may need to be resolved, 
etc. 


Within the context of the PCE architecture, it is therefore highly 
desirable to find a way to introduce new path computation 
capabilities without reguiring modifying either the 
discovery/communication protocols or the PCC software. One way to 
achieve this objective is to consider path selection constraints, 
their relaxations, and objective functions, as path computation 
reguest-specific policies. Furthermore, such policies may be 
configured and managed by a network operator as any other policies 
and may be interpreted in real time by PCCs and PCEs. 
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2.2. 


There are a number of advantages and useful by-products of such an 
approach: 


New path computation capabilities may be introduced without 
changing PCE-PCC communication and discovery protocols or PCC 
software. Only the PCE module providing the path computation 
capabilities (referred to in this document as a path computation 
engine) needs to be updated. 


Existing constraints, objective functions and their relaxations may 
be aggregated and otherwise associated, thus producing new, more 
complex objective functions that do not reguire a change of code 
even on the PCEs supporting the functions. 


Different elements such as conditions, actions, variables, etc., 
may be reused by multiple constraints, diversities, and 
optimizations. 


PCCs and PCEs need to handle other (that is, not reguest-specific) 
policies. Path computation-related policies of all types can be 
placed within the same policy repositories, managed by the same 
policy management tools, and interpreted using the same mechanisms. 
Also, policies need to be supported by PCCs and PCEs independent of 
the peculiarities of a specific PCC-PCE communication protocol, see 
[PCEP]. Thus, introducing a new (reguest-specific) type of policy 
describing constraints and other elements of a path computation 
reguest will be a natural and relatively inexpensive addition to 
the policy-enabled path computation architecture. 


Policy Attributes 


This section provides a summary listing of the policy attributes that 
may be included in the policy exchanges described in the scenarios 
that follow. This list is provided for guidance and is not intended 
to be exclusive. Implementation of this framework might include 
additional policy attributes not listed here. 


Identities 


LSP head-end 
LSP destination 
— PCC 

— PCE 
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LSP identifiers 


- LSP head-end 

—- LSP destination 

- Tunnel identifier 

- Extended tunnel identifier 
— LSP ID 

- Tunnel name 


Requested LSP qualities 


- bandwidth 

- traffic parameters 

- LSP attributes 

- explicit path inclusions 
- explicit path exclusions 
- link protection level 

- setup priority 

- holding priority 

- preexisting LSP route 


Requested path computation behavior 


- objective function 
- other LSPs to be considered 


Additional policy information 


- Transparent policy information as received in Resource 
Reservation Protocol (RSVP)-TE 


2.3. Representative Policy Scenarios 


This section provides example scenarios of how policies may be 
applied using the PCE policy framework within the PCE architecture 
context. Actual networks may deploy one of the scenarios discussed, 
some combination of the presented scenarios, or other scenarios (not 
discussed). This section should not be viewed as limiting other 
applications of policies within the PCE architecture. 


2.3.1. Scenario: Policy Configured Paths 


A very simple usage scenario for PCE policy would be to use PCE to 
centrally administer configured paths.  Configured paths are composed 
of strict and loose hops in the form of Explicit Route Objects 
(EROS), see [RFC3209], and are used by one or more LSPs. Typically, 
such paths are configured at the LSP ingress. In the context of 
policy-enabled path computation, an alternate approach is possible. 
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In particular, service-specific policies can be installed that will 
provide configured path(s) for a specific service reguest. The 
reguest may be identified based on service parameters such as 
endpoints, requested OoS, or even a token that identifies the 
initiator of a service reguest. The configured path(s) would then be 
used as input to the path computation process, which would return 
explicit routes by expanding of all specified loose hops. 


Example of policy: 
if(service destination matches 10.132.12.0/24) 
Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1. 
else 
Compute path dynamically. 


TED synchronization 
mechanism (e.g., routing protocol) 


Inter-PCE Request /Response 
|Policy|<-->| PCE |<.+........... > (when present) 


| Request / 
| Response 
M 


Service  ------------- Signaling 
Request | [PCC] [Policy] | Protocol 
«------ >| Node | <------- > 
or Signaling  ------------- 
Protocol 


Figure 1: Policy Enabled PCC and PCE 


Path computation policies may be applied at either a PCC or a PCE, 
see Figure 1. In the PCC case, the configured path would be 
processed at the PCC and then passed to the PCE along with the PCE 
request, probably in the form of (inclusion) constraints. When 
applied at the PCE, the configured path would be used locally. Both 
cases require some method to configure and manage policies. In the 
PCC case, the real benefit would come when there is an automated 
policy distribution mechanism. 
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----»| Node |<--------- > | Node |<--------- >| Node 
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| Reguest/ 
| Response 
M 


Sêrvide --2-----2-- Signaling . ;2—-------- Signaling. ccc 
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 
----»t Node | <---------- > | Node | <---------- > | Node 


Figure 3: Multiple PCE Path Computation with Inter-PCE Communication 


Policy-configured paths may also be used in environments with 
multiple (more than one) cooperating PCEs (see Figures 2 and 3). For 
example, consider the case when there is limited TE visibility and 
independent PCEs are used to determine path(s) within each area of 
the TE visibility. In such a case, it may not be possible (or 
desirable) to configure entire explicit path(s) on a single PCE. 
However, it is possible to configure explicit path(s) for each area 
of the TE visibility and each responsible PCE. One by one, the PCEs 
would then map an incoming signaling request to appropriate 
configured path(s). Note that to make such a scenario work, it would 
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likely be necessary to start and finish the configured paths on TE 
domain boundary nodes. Clearly, consistent PCE Policy Repositories 
are also critical in this example. 


2.3.2. Scenario: Provider Selection Policy 


A potentially more interesting scenario is applying PC policies in 
multi-provider topologies. There are numerous interesting policy 
applications in such topologies. A rudimentary example is simple 
access control, that is, deciding which PCCs are permitted to reguest 
inter-domain path computation. 


A more complicated example is applying policy to determine which 
domain or network provider will be used to support a particular PCE 


request. Consider the topology presented in Figure 4. In this 
example, there are multiple transit domains available to provide a 
path from a source domain to a destination domain. Furthermore, each 


transit domain may have one or more options for reaching a particular 
domain. Each domain will need to select which of the multiple 
available paths will be used to satisfy a particular PCE request. 


In today's typical path computation process, TE reachability, 
availability, and metric are the basic criteria for path selection. 
However, policies can provide an important added consideration in the 
decision process. For example, transit domain A may be more 
expensive and provide lower delay or loss than transit domain B. 
Likewise, a transit domain may wish to treat PCE requests from its 
own customers differently than requests from other providers. In 
both cases, computation based on traffic engineering databases will 
result in multiple transit domains that provide reachability, and 
policies can be used to govern which PCE requests get better service. 
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4------- + 
4---------- -Transit4t---------- t 
4+---+---+ Domain 4+---+---+ 
| Transit | C | Transit | 
Ho + Domain | hs==tk===3+ | Domain+-------- + 
| | A +--+ | +--+ F | | 
+++ +---+---+ | | | +---+---+ +--+---+ 
| Source | | ts á | | |Target | 
|Domain | +===+Transit+===>+ | Domain | 
4+--+---+ +---+ Domain|---+ 4+--+---+ 
| £---4---4 | | D | | +---+---+ 
| |Transit| | T---4--- | [Transit | | 
Ho + Domain+--+ +--+ Domaint-------- + 
| B | | | c | 
4+---+---+ 4+---+---+ 4+---+---+ 
| | Transit | | 
Ho + Domain*---------- + 
| E | 
4+------- + 


Figure 4: Multi-Domain Network with Multiple Transit Options 


There are multiple options for differentiating which PCE requests use 
a particular transit domain and get a particular (better or worse) 
level of service. For example, a PCE in the source domain may use 
user- and request-specific policies to determine the level of service 
to provide. A PCE in the source domain may also use domain-specific 
policies to choose which transit domains are acceptable. A PCE in a 
transit domain may use reguest-specific policies to determine if a 
reguest is from a direct customer or another provider, and then use 
domain-specific policies to identify how the reguest should be 
processed. 


Example of policy: 
if(path computation reguest issued by a PCC within Source Domain) 
Route the path through Transit Domain A. 
else 
Route the path through Transit Domain B. 
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2.3.3. Scenario: Policy Based Constraints 


Another usage scenario is the use of policy to provide constraints in 
a PCE request. Consider an LSR with a policy enabled PCC, as shown 
in Figure 1, which receives a service request via signaling, 
including over a Network-Network Interface (NNI) or User Network 
Interface (UNI) reference point, or receives a configuration reguest 
over a management interface to establish a service. In either case, 
the path(s) needed to support the service are not explicitly 
specified in the message/reguest, and hence path computation is 
needed. 


In this case, the PCC may apply user- or service-specific policies to 
decide how the path selection process should be constrained, that is, 
which constraints, diversities, optimization criterion, and 
constraint relaxation strategies should be applied in order for the 
service LSP(s) to have a likelihood to be successfully established 
and provide necessary OoS and resilience against network failures. 
When deciding on the set of constraints, the PCC uses as an input all 
information it knows about the user and service, such as the contents 
of the received message, port ID over which message was received, 
associated VPN ID, signaling/reference point type, reguest time, etc. 
Once the constraints and other parameters of the reguired path 
computation are determined, the PCC generates a path computation 
reguest that includes the reguest-specific policies that describe the 
determined set of constraints, optimizations, and other parameters 
that indicate how the reguest is to be considered in the path 
computation process. 


Example of policy: 
if(LSP belongs to a WDM layer network) 

Compute the path with wavelength continuity constraint with the 
maximum Optical Signal Noise Ratio (OSNR) at the path end 
optimization. 

else if(LSP belongs to a connection oriented Ethernet layer network) 
Compute the path with minimum end-to-end delay. 

else 
Compute the shortest path. 


The PCC may also apply server-specific policies in order to select 
which PCE to use from the set of known (i.e., discovered or 
configured) PCEs. The PCC may also use server-specific policies to 
form the reguest to match the PCE's capabilities so that the reguest 
will not be rejected and has a higher likelihood of being satisfied 
in an efficient way. An example of a reguest modification as the 
result of a server-specific policy is removing a constraint not 
supported by the PCE. Once the policy processing is completed at the 
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PCC, and the path computation reguest resulting from the original 
service reguest is updated by the policy processing, the reguest is 
sent to the PCE. 


Example of policy: 
if(LSP belongs to a WDM layer network) 
Identify a PCE supporting wavelength continuity and optical 
impairment constraints; 
Send a reguest to such PCE, reguesting path computation with the 
following constraints: 
a) wavelength continuity; 
b) maximum Polarization Mode Dispersion (PMD) at the path end. 
if(the path computation fails) remove the maximum PMD constraint 
and try the computation again. 


The PCE that receives the request validates and otherwise processes 
the reguest, applying the policies found in the reguest as well as 
any policies that are available at the PCE, e.g., client- and domain- 
specific policies. As a result of the policy processing, the PCE may 
decide to reject the reguest. 


Example of policy: 

Authenticate the PCC reguesting the path computation using the 
PCC ID found in the path computation reguest; 

Reject the request if the authentication fails. 


The PCE also may decide to respond with one or several pre-computed 
paths if user- or client-specific policies instruct the PCE to do so. 
If the PCE decides to satisfy the reguest by performing a path 
computation, it determines if it needs the cooperation of other PCEs 
and defines parameters for path computations to be performed locally 
and remotely. After that, the PCE instructs a co-located path 
computation engine to perform the local path computation(s) and, if 
necessary, sends path computation reguests to one or more other PCEs. 
It then waits for the responses from the local path computation 
engine and, when used, the remote PCE. It then combines the 
resulting paths and sends the result back to the reguesting PCC. The 
response may indicate policies describing the resulting paths, their 
characteristics (summary cost, expected end-to-end delay, etc.), as 
well as additional information related to the reguest, e.g., which 
constraints were honored, which were dismissed, and which were 
relaxed and in what way. 
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Example of policy: 
if(the path destination belongs to domain A) 
Instruct local path computation engine to perform the path 
computation; 
else 
Identify the PCE supporting the destination domain; 
Send path computation reguest to such PCE; 
Wait for and process the response. 
Send the path computation response to the reguesting PCC. 


The PCC processes the response and instructs the LSR to encode the 
received path(s) into the outgoing signaling message(s). 


2.3.4. Scenario: Advanced Load Balancing (ALB) Example 


Figure 5 illustrates a problem that stems from the coupling between 
BGP and IGP in the BGP decision process. If a significant portion of 
the traffic destined for the data center (or customer network) enters 
a PCE-enabled network from AS 1 and all IGP links' weights are the 
same, then both PE3 and PE4 will prefer to reach the data center 
using the routes advertised by PE2. PE5 will use the router-IDs of 
PE1 and PE2 to break the tie and might therefore also select to use 
the path through PE2 (if the router ID of PE2 is smaller than that of 
PE1). Either way, the net result is that the link between PE2 and CE 
will carry most of the traffic while the link between PE1 and the 
Customer Edge (CE) will be mostly idle. 
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AS 1 
+---+ +---+ +=---+ 
|PE8| |PE9| |PE10| 
+-—-+ +---+ +----+ 


Bat |PE3 | |PE4 | |PE5|...... 
+---+  +---+ +--+ 
ar +=--+ \ / =f +---+ 
|PE2 | +--+__/ / |PE6 | 
+--+ / +---+ |P1| +--+ / +---+ 
Customer |CE|= , +--+ |P2| 
Network +--+ \_+---+ \ +--+ . 
j |PE1| +--+ / x---x . PCE used 
YW Ca +---+ |P3 | |PCE| . by all 
+--+ | x---x . ASO nodes 
AS 0 toc 
ee NA (Pra 
+---+ 


Figure 5: Advanced Load Balancing 


This is a common problem for providers and customers alike. Analysis 
of Netflow records, see [IRSCP], for a large ISP network on a typical 
day has shown that for 71.8% of multi-homed customers, there is a 
complete imbalance, where the most loaded link carries all the 
traffic and the least loaded link carries none. 


PCE policies can address this problem by basing the routing decision 
at the ingress routers on the offered load towards the multi-homed 
customer. For example, in Figure 5, PCE policies could be configured 
such that traffic load is monitored (e.g., based on Netflow data) at 
ingress routers PE3 to PE7 towards the data center prefixes served by 
egress routers PEl and PE2. Using this offered load information, the 
path computations returned by PCE, based on the enabled PCE policies, 
can direct traffic to the appropriate egress router, on a per-ingress 
router basis. For example, the PCE path computation might direct 
traffic from both PE4 and PE5 to egress PE1, thus overriding the 
default IGP based selection. Alternatively, traffic from each 
ingress router to each egress link could be split 50-50. 


This scenario is a good example of how a policy-governed PCE can 
account for some information that was not or cannot be advertised as 
TE link/node attributes, and, therefore, cannot be subject for 
explicit path computation constraints. More generally, such 
information can be pretty much anything. For example, traffic demand 
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forecasts, flow monitoring feedback, any administrative policies, 
etc. Further examples are described in [IRSCP] of how PCE policies 
might address certain network routing problems, such as selective 
distributed denial-of-service (DDoS) blackholing, planned 


maintenance, and VPN gateway selection. 


Example of policy: 
for(all traffic flows destined to Customer Network) 
if(flow ingresses on PE3, PE4, or PE5) 
Route the flow over PEl. 
else 
Route the flow over PE2. 


3. Requirements 
The following requirements must be addressed by mechanisms and 


protocols that enable policy-based control over path computation 
requests and decisions: 


(G)MPLS path computation-specific 

The mechanisms must meet the policy-based control reguirements 
specific to the problem of path computation using RSVP-TE as the 
signaling protocol on MPLS and GMPLS LSRs. 


- Support for non-(G)MPLS PCCs 
The mechanisms must be sufficiently generic to support non- (G)MPLS 
(LSR) clients such as a Network Management System (NMS), or network 
planner, etc. 


- Support for many policies 
The mechanisms must include support for many policies and policy 
configurations. In general, the determination and configuration of 
viable policies are the responsibility of the service provider. 


- Provision for monitoring and accounting information 
The mechanisms must include support for monitoring policy state and 


provide access information. In particular, mechanisms must provide 
usage and access information that may be used for accounting 
purposes. 


- Fault tolerance and recovery 
The mechanisms must include provisions for fault tolerance and 
recovery from failure cases such as failure of PCC/PCE PDPs, 
disruption in communication that separate a PCC/PCE PDP from its 
associated PCC/PCE PEPs. 
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- Support for policy-ignorant nodes 
The mechanisms should not be mandatory for every node in a network. 
Policy-based path computation control may be enforced at a subset 
of nodes, for example, on boundary nodes within an administrative 
domain. These policy-capable nodes will function as trusted nodes 
from the point of view of the policy-ignorant nodes in that 
administrative domain. Alternatively, policy may be applied solely 
on PCEs with all PCCs being policy-ignorant nodes. 


- Scalability 
One of the important requirements for the mechanisms is 
scalability. The mechanisms must scale at least to the same extent 
that RSVP-TE signaling scales in terms of accommodating multiple 
LSPs and network nodes in the path of an LSP. There are several 
sensitive areas in terms of scalability of policy-based path 
computation control. First, not every policy-aware node in an 
infrastructure should be expected to contact a remote PDP. This 
would cause potentially long delays in verifying requests. 
Additionally, the policy control architecture must scale at least 
as well as RSVP-TE protocol based on factors such as the size of 
RSVP-TE messages, the time required for the network to service an 
RSVP-TE request, local processing time required per node, and local 
memory consumed per node. These scaling considerations are of 
particular importance during re-routing of a set of LSPs. 


- Security and denial-of-service considerations 
The policy control architecture, protocols, and mechanisms must be 
Secure as far as the following aspects are concerned: 


o First, the mechanisms proposed must minimize theft and denial- 
of-service threats. 


o Second, it must be ensured that the entities (such as PEPs and 
PDPs) involved in policy control can verify each other's 
identity and establish necessary trust before communicating. 


- Inter-AS and inter-area requirements 
There are several inter-AS policy-related requirements discussed in 
[RFC4216] and [RFC5376], and inter-area policy-related requirements 
discussed in [RFC4927]. These requirements must be addressed by 
policy-enabled PCE mechanisms and protocols. 


It should be noted that this document only outlines the communication 
elements and mechanisms needed to allow a wide variety of possible 
policies to be applied for path computation control. It does not 
include any discussion of any specific policy behavior, nor does it 
define or reguire use of specific policies. 
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4. Path Computation Policy Information Model (PCPIM) 
The Policy Core Information Model (PCIM) introduced in [RFC3060] and 
expanded in [RFC3460] presents the object-oriented information model 
for representing general policy information. 


This model defines two hierarchies of object classes: 


- Structural classes representing policy information and control of 
policies. 


— Association classes that indicate how instances of the structural 
classes are related to each other. 


These classes can be mapped to various concrete implementations, for 
example, to a directory that uses Lightweight Directory Access 


Protocol version 3 (LDAPv3) as its access protocol. 


Figure 6 shows an abstract from the class inheritance hierarchy for 
PCIM. 
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ManagedElement (abstract) 


t--Policy (abstract) 


+---PolicySet (abstract) 


| t---PolicyGroup 


t---PolicyRule 


t---PolicyCondition (abstract) 


t---PolicyTimePeriodCondition 


t---VendorPolicyCondition 


t---SimplePolicyCondition 


t---CompoundPolicyCondition 


t---CompoundFilterCondition 


---PolicyAction (abstract) 


| 

| 

| 

| 

| 

| 

| 

| 

+ 

| 

| t---VendorPolicyAction 
| | 

| t---SimplePolicyAction 
| 

+ 

| 

| 

| 

| 

+ 


t---CompoundPolicyAction 


---PolicyVariable (abstract) 


t---PolicyExplicitVariable 


t---PolicyImplicitVariable 
t---(subtree of more specific classes) 
---PolicyValue (abstract) 


t---(subtree of more specific classes) 


Figure 6: PCIM Class Inheritance 


December 2008 


The policy classes and associations defined in PCIM are sufficiently 
generic to allow them to represent policies related to anything. 
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Policy models for application-specific areas such as the Path 
Computation Service may extend the PCIM in several ways. The 
preferred way is to use the PolicyGroup, PolicyRule, and 
PolicyTimePeriodCondition classes directly as a foundation for 
representing and communicating policy information. Then, specific 
subclasses derived from PolicyCondition and PolicyAction can capture 
application-specific definitions of conditions and actions of 
policies. 


The Policy Ouality of Service Information Model [RFC3644] further 
extends the PCIM to represent OoS policy information for large-scale 
policy domains. New classes introduced in this document describing 
OoS- and RSVP-related variables, conditions, and actions can be used 
as a foundation for the PCPIM. 


Detailed description of the PCPIM will be provided in a separate 
document. 


5. Policy-Enabled Path Computation Framework Components 


The following components are defined as part of the framework to 
support policy-enabled path computation: 


- PCE Policy Repository 
A database from which PCE policies are available in the form of 
instances of PCPIM classes. PCE Policies are configured and 
managed by PCE Policy Management Tools; 


- PCE Policy Decision Point (PCE-PDP) 
A logical entity capable of retrieving relevant path computation 
policies from one or more Policy Repositories and delivering the 
information to associated PCE-PEP (s); 


- PCE Policy Enforcement Point (PCE-PEP) 
A logical entity capable of issuing device-specific Path 
Computation Engine configuration requests for the purpose of 
enforcing the policies; 


—- PCC Policy Decision Point (PCC-PDP) 
A logical entity capable of retrieving relevant path computation 
policies from one or more Policy Repositories and delivering the 
information to associated PCC-PEP(s); 


- PCC Policy Enforcement Point (PCC-PEP) 
A logical entity capable of issuing device-specific Path 
Computation Service User configuration requests for the purpose of 
enforcing the policies. 
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From the policy perspective a PCC is logically decomposed into two 
parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located 
with a Path Computation Service User entity that reguires remote path 


computation (for example, the GMPLS control plane of an LSR). The 
PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) 
or separated. In the latter case, they talk to each other via such 


protocols as SOAP [W3CSOAP] or BEEP [RFC3080]. 


Likewise, a PCE is logically decomposed into two parts: PCE-PEP and 
PCE-PDP. When present, PCE-PEP is co-located with a Path Computation 
Engine entity that actually provides the Path Computation Service 
(that is, runs path computation algorithms).  PCE-PEP and PCE-PDP may 
be physically co-located or separated. In the later case, they 
communicate using such protocols as SOAP and/or BEEP. 


PCC-PDP/PCE-PDP may be co-located with, or separated from, an 
associated PCE Policy Repository. In the latter case, the PDPs use 
some access protocol (for example, LDAPv3 or SNMP). The task of PDPs 
is to retrieve policies from the repository (or repositories) and 
convey them to respective PEPs either in an unsolicited way or upon 
the PEP's reguests. 


A PCC-PEP may receive policy information not only from PCC-PDP(s) but 
also from PCE-PEP(s) via PCC-PCE communication and/or PCE discovery 
protocols. Likewise, a PCE-PEP may receive policy information not 
only from PCE-PDP(s) but also from PCC-PEP(s), via the PCC-PCE 
communication protocol [PCEP]. 


Any given policy can be interpreted (that is, translated into a 
seguence of concrete device specific configuration reguests) either 
on a PDP or on the associated PEP or partly on the PDP and partly on 
the PEP. 


Generally speaking, the task of the PCC-PEP is to select the PCE and 
build path computation reguests applying service-specific policies 
provided by the PCC-PDP. The task of the PCE-PEP is to control path 
computations by applying reguest-specific policies found in the 
reguests as well as client-specific and domain-specific policies 
supplied by the PCE-PDP. 


6. Policy Component Configurations 

6.1. PCC-PCE Configurations 
The PCE policy architecture supports policy being applied at a PCC 
and at a PCE. While the architecture supports policy being applied 


at both, there is no reguirement for policy to always be applied at 
both, or even at either. The use of policy in a network, on PCCs, 
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and on PCEs, is a specific network design choice. Some networks may 
choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 
8), and others at both PCCs and PCEs (Figure 9). Regardless of where 


policy is applied, it must be applied in a consistent fashion in 
order to achieve the intended results. 


AS Policy HE da y i Ed 
| PCC-PDP |«--------- | PCE Policy Repository | 
| e.g., SOAP 
V 
--------- PCEP --------- 
| PCC-PEP |«------------------------------------------- >| PCE 


==p====== PCC-PCE Communication Protocol EN UR S 
Figure 7: Policies Applied on PCC Only 


Along with supporting flexibility in where policy may be applied, the 
PCE architecture is also flexible in terms of where specific types of 
policies may be applied. Also, the PCE architecture allows for the 
application of only a subset of policy types. [RFC4655] defines 
several PC policy types. Each of these may be applied at either a 
PCC or a PCE or both. Clearly, when policy is only applied at PCCs 


or at PCEs, all PCE policy types used in the network must be applied 
at those locations. 
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tU O SS Policy A 
PCE Policy Repository | -------- >| PCE-PDP 
e.g., SOAP | 
V 
--------- PCEP --------- 
PCC <------------------------------------------- >| PCE-PEP | 


cud PCC-PCE Communication Protocol cc cen 
Figure 8: Policies Applied on Only 


In the case where policy is only applied at a PCE, it is expected 
that the PCC will pass to the PCE all information about the service 
that it can gather in the path computation reguest (most likely in 
the form of PCPIM policy variables). The PCE is expected to 
understand this information and apply appropriate policies while 
defining the actual parameters of the path computation to be 
performed. Note that in this scenario, the PCC cannot apply server- 
specific or any other policies, and PCE selection is static. 


When applying policy at both the PCC and PCE, it is necessary to 
select which types of policies are applied at each. In such 
configurations, it is likely that the application of policy types 
will be distributed across the PCC and PCE rather than applying all 
of them at both. For example, user-specific and server-specific 
policies may be applied at a PCC, reguest- and client-specific 
policies may be applied at a PCE, while domain-specific policies may 
be applied at both the PCC and PCE. 


In the case when policy is only applied at a PCC, the PCC must apply 
all the types of reguired policies, for example user-, service-, 
server-, and domain-specific policies. The PCC uses the policies to 
construct a path computation reguest that appropriately represents 
the applied policies. The reguest will necessarily be limited to the 
set of "basic" (that is, non-policy capable) constraints explicitly 
defined by the PCC-PCE communication protocol. 
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6.2. Policy Repositories 
Within the policy-enabled path computation framework policy 
repositories may be used in a single or multiple PCE policy 
repository configuration: 


o) Single PCE Policy Repository 


In this configuration, there is a single PCE Policy Repository shared 
between PCCs and PCEs. 


ETE Policy a HPA Y Y Yy. BOLETA RARA 
| PCC-PDP |«--------- | PCE Policy Repository | -------- >| PCE-PDP 
| e.g., SOAP e.g., SOAP | 
V V 
--------- PCEP --------- 
| PCC-PEP |«------------------------------------------- >| PCE-PEP | 


a PCC-PCE Communication Protocol mne 
Figure 9: Single PCC/PCE Policy Repository 
o) Multiple PCE Policy Repositories 
The repositories in this case may be fully or partially synchronized 
by some discovery/synchronization management protocol or may be 
completely independent. Note that the situation when PCE Policy 


Repository A exactly matches PC Policy Repository B, results in the 
single PCE Policy Repository configuration case. 
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| PCE Policy | | PCE Policy | 
---| Repository A | | Repository B |--- 

"MM Sy Lc | 

| | 

| Policy a Policy b | 

| | 

V V 
| PCC-PDP | | PCE-PDP | 

| e.g., SOAP e.g., SOAP | 

V V 

--------- PCEP --------- 

| PCC-PEP |«------------------------------------------- >| PCE-PEP | 


TRE SS PCC-PCE Communication Protocol EPR 
Figure 10: Multiple PCE/PCC Policy Repositories 
6.3. Cooperating PCE Configurations 


The previous section shows the relationship between PCCs and PCEs. A 
parallel relationship exists between cooperating PCEs, and, in fact, 
this relationship can be viewed as the same as the relationship 
between PCCs and PCEs. The one notable difference is that there will 
be cases where having a shared PCE Policy Repository will not be 
desirable, for example, when the PCEs are managed by different 
entities. Note that in this case, it still remains necessary for the 
policies to be consistent across the domains in order to identify 
usable paths. The other notable difference is that a PCE, while 
processing a path computation request, may need to apply requester- 
specific (that is, client-specific) policies in order to modify the 
request before sending it to other cooperating PCE(s). This 
relationship is particularly important as the PCE architecture allows 
for configuration where all PCCs are not policy-enabled. 


The following are example configurations. These examples do not 
represent an exhaustive list and other configurations are expected. 


o) Single Policy Repository 
In this configuration, there is a single PCE Policy Repository shared 
between PCEs. This configuration is likely to be useful within a 


single administrative domain where multiple PCEs are provided for 
redundancy or load distribution purposes. 
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ER Policy a A Policy bs.c-—————5c-- 
| PCE-PDP |«--------- | PCE Policy Repository | -------- >| PCE-PDP 
| e.g., SOAP e.g., SOAP | 
V V 
| PCE-PEP |«------------------------------------------- >| PCE-PEP | 


====2=22= PCE-PCE Communication Protocol cc coc 
Figure 11: Single PCC Policy Repository 
o) Multiple Policy Repositories 


The repositories in this case may be fully or partially synchronized 
by some discovery/synchronization management protocol(s) or may be 
completely independent. In the multi-domain case, it is expected 
that the repositories will be distinct, providing, however, 
consistent policies. 


| PCE Policy | | PCE Policy | 
---| Repository A | | Repository B |--- 

ME M ZZ LLL AL A | 

| | 

| Policy a Policy b | 

| | 

V V 
| PCE-PDP | | PCE-PDP | 

| e.g., SOAP e.g., SOAP | 

V | ; V 

--------- PCEP --------- 

| PCE-PEP |«------------------------------------------- >| PCE-PEP | 


Fr PCC-PCE Communication Protocol === 252 


Figure 12: Multiple PCC Policy Repositories 
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6.4. Policy Configuration Management 


The management of path computation policy information used by PCCs 
and PCEs is largely out of scope of the described framework. The 
framework assumes that such information is installed, removed, and 
otherwise managed using typical policy management technigues. Policy 
Repositories may be populated and managed via static configuration, 
standard and proprietary policy management tools, or even dynamically 
via policy management/discovery protocols and applications. 


7. Inter-Component Communication 
7.1. Policy Communication 


Flexibility in the application of policy types is imperative from the 
architecture perspective. However, this commodity implies added 
complexity on the part of the PCE-related communication protocols. 


One added complexity is that PCE communication protocols must carry 
certain information to support various policy types that may be 
applied. For example, in the case where policy is only applied at a 
PCE, a PCC-PCE reguest must carry sufficient information for the PCE 
to apply service- or user-specific policies. This does imply that a 
PCC must have sufficient understanding of what policies can be 
applied at the PCE. Such information may be obtained via local 
configuration, static coding, or even via a PCE discovery mechanism. 
The PCC must also have sufficient understanding to properly encode 
the required information for each policy type. 


Another added complexity is that PCE communication protocols must 
also be able to carry information that may result from a policy 
decision. For example, user- or service-specific policy applied at a 
PCC may result in policy-related information that must be carried 
along with the reguest for use by a PCE. This complexity is 
particularly important as it may be used to introduce new path 
computation parameters (e.g., constraints, objection functions, etc.) 
without modification of the core PCC and PCE. This communication 
will likely simply require the PCE communication protocols to support 
opaque policy-related information elements. 


A final added complexity is that PCE communication protocols must 
also be able to support updated or unsolicited responses from a PCE. 
For example, changes in PCE policy may force a change to a previously 
provided path. Such updated or unsolicited responses may contain 
information that the PCC must act on, and may contain policy 
information that must be provided to a PCC. 
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PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- 
response type PCC-PCE Communication Protocol, i.e., [PCEP]. This 
document makes no assumptions as to what exact protocol is used to 
support this communication. This document does assume that the 
semantics of a path computation reguest are sufficiently abstract and 
general, and support both PCE-PCC and PCE-PCE communication. 


From a policy perspective, a path computation reguest should include 
at a minimum: 


o One or more source addresses; 

o One or more destination addresses; 

o Computation type (P2P (point to point), P2MP (point to multipoint), 
MP2P (multipoint to point), etc.); 

o Number of reguired paths; 

o Zero or more policy descriptors in the following format: 
<policy name>, 


<policy variablel name>, <paramll>, <paraml2>,...,<paramlN> 
<policy variable2 name>, <param21>, <paraml2>,...,<param2N> 
<policy variableM name>, <paramMl>, <paramM2>,...,<paramMN> 


A successful path computation response, at minimum, should include 
the list of computed paths and may include policies (in the form of 
policy descriptors as in path computation reguest, see above) for use 
in evaluating and otherwise applying the computed paths. 


PCC-PCE Communication Protocol provides transport for policy 
information and should not understand nor make any assumptions about 
the semantics of policies specified in path computation reguests and 
responses. 


Note: This document explicitly allows for (but does not reguire) the 
PCC to decide that all necessary constraints, objective functions, 
etc. pertinent to the computation of paths for the service in 
guestion are to be determined by the PCE performing the computation. 
In this case, the PCC will use a set of policies (more precisely, 
PCPIM policy variables) describing the service-specific information. 
These policies may be placed within the path computation reguest and 
delivered to the PCE via a PCC-PCE communication protocol such as 
[PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand 
this information and use it to determine the constraints and 
optimization functions applying local policies (that is, policies 
locally configured or provided by the associated PCE-PDP(s)). 
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7.2. PCE Discovery Policy Considerations 


Dynamic PCE discovery allows for PCCs and PCEs to automatically 
discover a set of PCEs (including information required for the PCE 
selection). It also allows for PCCs and PCEs to dynamically detect 
new PCEs or any modification of PCEs status. Policy can be applied 
in two ways in this context: 


1. Restricting the scope of information distribution for the 
mandatory set of information (in particular the PCE presence and 
location). 


2. Restricting the type and nature of the optional information 
distributed by the discovery protocol. The latter is also subject 
to policy since the PCE architecture allows for distributing this 
information using either PCE discovery protocol(s) or PCC-PCE 
communication protocol(s). One important policy decision in this 
context is the nature of the information to be distributed, 
especially, when this information is not strictly speaking 
"discovery" information, rather, the PCE state changes.  Client- 
specific and domain-specific policies may be applied when deciding 
whether this information should be distributed and to which 
clients of the path computation service (that is, which PCCs 
and/or PCEs). 


Another place where policy applies is at the administrative 
boundaries. In multi-domain networks, multiple PCEs will communicate 
with each other and across administrative boundaries. In such cases, 
domain-specific policies would be applied to 1) filter the 
information exchanged between peering PCEs during the discovery 
process (to the bare minimum in most cases if at all allowed by the 
security policy) and 2) limit the content of information being passed 
in path computation reguest and responses. 


8. Path Computation Sequence of Events 


This section presents a non-exhaustive list of representative 
scenarios. 


8.1. Policy-Enabled PCC, Policy-Enabled PCE 


When a GMPLS LSR receives a Setup (RSVP Path) message from an 
upstream LSR, the LSR may decide to use a remote Path Computation 
Entity. The following seguence of events occurs in this case: 


- A PCC-PEP co-located with the LSR applies the service-specific 
policies to select a PCE for the service path computation as well 
as to build the path computation reguest (that is, to select a list 
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of policies, their variables, conditions and actions expressing 
constraints, diversities, objective functions and relaxation 
strategies appropriate for the service path computation). The 
policies may be: 


a) Statically configured on the PCC-PEP; 


b) Communicated to the PCC-PEP by a remote or local PCC-PDP via 
protocol such as SOAP either proactively (most of the cases) or 
upon an explicit reguest by the PCC-PEP in cases when some 
specifics of the new service have not been covered yet by the 
policies so far known to the PCC-PEP). 


The input for the decision process on the PCC-PEP is the 
information found in the signaling message as well as any other 
service-specific information such as port ID over which the message 
was received, associated VPN ID, the reference point type (UNI, 
E-NNI, etc.) and so forth. After the path computation reguest is 
built, it is sent directly to the PCE-PEP using the PCC-PCE 
Communication Protocol, e.g., [PCEP]. 


- PCE-PEP validates and otherwise processes the request applying the 
policies found in the reguest- as well as client- and domain- 


specific policies. The latter, again, may be either statically 
configured on the PCE-PEP or provided by the associated local or 
remote PCE-PDP via a protocol such as SOAP. The outcome of the 


decision process is the following information: 
a) Whether the request should be satisfied, rejected, or dismissed. 


b) The sets of sources and destinations for which paths should be 
locally computed. 


c) The set of constraints, diversities, optimization functions, and 
relaxations to be considered in each of locally performed path 
computation. 


d) The address of the next-in-chain PCE. 


e) The path computation reguest to be sent to the next-in-chain 
PCE. 


The PCE-PEP instructs a co-located path computation engine to 
perform the local path computation(s) and, if necessary, sends the 
path computation reguest to the next-in-chain PCE using a PCC-PCE 
Communication Protocol. Then, it waits for the responses from the 
local path computation engine and the remote PCE, combines the 
resulting paths, and sends them back to the PCC-PEP using the PCC- 
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PCE Communication Protocol. The response contains the resulting 
paths as well as policies describing some additional information 
(for example, which of constraints were honored, which were 
dismissed, and which were relaxed and in what way). 


- PCC-PEP instructs the signaling subsystem of the GMPLS LSR to 
encode the received path(s) into the outgoing Setup message(s). 


8.2. Policy-Ignorant PCC, Policy-Enabled PCE 


This case parallels the previous example, but the user- and service- 
specific policies should be applied at the PCE as the PCC is policy 
ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) 
message from an upstream LSR, the LSR may decide to use a non-co- 
located Path Computation Entity. The following seguence of events 
occurs in this case: 


- The PCC constructs a PCE request using information found in the 
signaling/provisioning message as well as any other service- 
specific information such as port ID over which the message was 
received, associated VPN ID, the reference point type (UNI, E-NNI, 
etc.) and so forth. This information is encoded in the reguest in 
the form of policy variables. After the request is built, it is 
sent directly to the PCE-PEP using a PCC-PCE Communication 
Protocol. 


- PCE-PEP validates and otherwise processes the request interpreting 
the policy variables found in the request and applying user-, 
service-, client-, and domain-specific policies to build the actual 
path computation request. The policies, again, may be either 
statically configured on the PCE-PEP or provided by the associated 
local or remote PCE-PDP via a protocol such as SOAP. The outcome 
of the decision process is the following information: 


a) Whether the request should be satisfied, rejected, or dismissed. 


b) The sets of sources and destinations for which paths should be 
locally computed. 


C) The set of constraints, diversities, optimization functions, and 
relaxations to be considered in each of locally performed path 
computation. 


d) The address of the next-in-chain PCE. 


e) The path computation request to be sent to the next-in-chain 
PCE. 
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The PCE-PEP instructs a co-located path computation engine to 
perform the local path computation(s) and, if necessary, sends the 
path computation request to the next-in-chain PCE using the PCC-PCE 
Communication Protocol. Then, it waits for the responses from the 
local path computation engine and the remote PCE, combines the 
resulting paths, and sends them back to the PCC-PEP using the PCC- 
PCE Communication Protocol. The response contains the resulting 
paths as well as policies describing some additional information 
(for example, which of constraints were honored, which were 
dismissed, and which were relaxed and in what way) 


- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 
encode the received path(s) into the outgoing Setup message(s). 


Introduction of New Constraints 


An important aspect of the policy-enabled path computation framework 
discussed above is the ability to introduce new constraints with 
minimal impact. In particular, only those components and mechanisms 
that will use a new constraint need to be updated in order to support 
the new constraint.  Importantly, those components and mechanisms 
that will not use the new constraint must not require any change in 
order for the new constraint to be utilized. For example, the PCE 
communication protocols must not require any changes to support new 
constraints. Likewise, PCC and PCEs that will not process new 
constraints must not require any modification. 


Consider the case where a PCE has been upgraded with software 
supporting optical physical impairment constraint, such as 
Polarization Mode Dispersion (PMD), that previously was not supported 
in the domain. In this case, one or more new policies will be 
installed in the PCE Policy Repository (associated with the PCE) 
defining the constraint (rules that determine application criteria, 
set of policy variables, conditions, actions, etc.) and its 
relaxation strategy (or strategies). The new policies will be also 
propagated into other PCE Policy Repositories within the domain via 
discovery and synchronization protocols or via local configuration. 
PCE-PDPs and PCC-PDPs will then retrieve the corresponding policies 
from the repository (or repositories). From then on, PCC-PDPs will 
instruct associated PCC-PEPs to add the new policy information into 
path computation requests for services with certain parameters (for 
example, for services provisioned in the optical channel (OCh) 
layer). 


It is important to note that policy-enabled path computation model 
naturally solves the PCE capability discovery issues. Suppose a PCE 
working in a single PCE Policy Repository configuration starts to 
support a new constraint. Once a corresponding policy installed in 
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the repository, it automatically becomes available for all repository 
users, that is, PCCs. In the multi-repository case some policy 
synchronization must be provided; however, this problem is one of the 
management plane which is solved already. 


10. Security Considerations 
This document adds to the policy security considerations mentioned in 
[RFC4655]. In particular, it is now necessary to consider the 
security issues related to policy information maintained in PCE 
Policy Repositories and policy-related transactions. The most 
notable issues, some of which are also listed in [RFC4655], are: 


- Unauthorized access to the PCE Policy Repositories; 


- Interception of policy information when it is retrieved from the 
repositories and/or transported from PDPs to PEPs; 


- Interception of policy-related information in path computation 
reguests and responses; 


o Impersonation of user and client identities; 
o Falsification of policy information and/or PCE capabilities; 


o Denial-of-service attacks on policy-related communication 
mechanisms. 


As with [RFC4655], it is expected that PCE solutions will address the 
PCE aspects of these issues in detail. 
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